home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20031118-20041115
/
000364_jaltman2@nyc.rr.com_Thu Aug 19 10:06:28 2004.msg
< prev
next >
Wrap
Internet Message Format
|
2004-11-14
|
3KB
Path: newsmaster.cc.columbia.edu!newsfeed1.nycmny01.us.to.verio.net!nntp2.tagonline.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!ra.nrl.navy.mil!HSNX.atgi.net!cyclone-sf.pbi.net!216.196.98.144!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!gnilink.net!cyclone.rdc-nyc.rr.com!news-out.nyc.rr.com!twister.nyc.rr.com.POSTED!53ab2750!not-for-mail
Message-ID: <41240394.2080502@nyc.rr.com>
From: Jeffrey Altman <jaltman2@nyc.rr.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Firewall Issue
References: <417dde32.0408180838.7d3d74ef@posting.google.com> <41238A69.4070205@nyc.rr.com> <417dde32.0408181353.ad47f9a@posting.google.com>
In-Reply-To: <417dde32.0408181353.ad47f9a@posting.google.com>
X-Enigmail-Version: 0.84.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 39
Date: Thu, 19 Aug 2004 01:32:54 GMT
NNTP-Posting-Host: 24.193.46.55
X-Complaints-To: abuse@rr.com
X-Trace: twister.nyc.rr.com 1092879174 24.193.46.55 (Wed, 18 Aug 2004 21:32:54 EDT)
NNTP-Posting-Date: Wed, 18 Aug 2004 21:32:54 EDT
Organization: Road Runner - NYC
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:15126
FTP works this way. The server has a standard port for command
channels, port 21. The client allocates a random port number to
use when making a connection and then connects to port 21. If the
client does not randomize its port number then it would be impossible
for two processes on the same machine to connect to the same FTP
server.
The data connection depends entirely on which side is being the
acceptor. In the original "active" model, the client allocates
a random port number and offers it to the server. The server
then uses port 20 to connect to the client's port.
This does not work through firewalls and NATs. Therefore, the passive
model was developed. In the passive model, the server allocates a
random port and publishes it to the client. The client then allocates
a random port number and connects to the server. The reason the client
uses a random value is because the server may have a small number of
reused ports.
Kermit defaults to the passive model as does almost every other current
FTP client. FTP servers are assumed to be in public space; the FTP
client is assumed to be in private space given the current Internet
architecture.
Jeffrey Altman
Don L wrote:
> I'm waiting for some clarification on what they mean by "random high
> ports", but I suspect they are talking about the command and data
> ports the client PC is selecting and not those of the FTP server. If
> my understanding is correct, the client PC can randomly assign its own
> command and data ports.
>
> If this is the case (they are talking about the client PC's ports), is
> there a way to assign the command and data ports of the client PC
> using Kermit?